Lookerベスト・プラクティス：Lookerパフォーマンス概要 #looker

「カスタマーストーリー」を支えるツール特集

#ビッグデータ

#ビジネス・アナリティクス

#Looker

しんや

2019.10.14

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Lookerではトピック毎のベストプラクティスを個別にドキュメントやナレッジベースとしてまとめています。当エントリではその中から、『Lookerパフォーマンス概要』についてご紹介したいと思います。

Performance Overview – Looker Help Center

Lookerを使用する企業はそれぞれ、専用のサーバまたはクラスタを有します。イコール、グローバルなLookerサーバーという概念ではありません。ブラウザからLookerにログインを行うと、ブラウザはリクエストをサーバに送信します。サーバはそれに対しレスポンスを返し、ブラウザがそのレスポンスを表示します。

その後、Lookerはデータベースへの接続を行います。

例).Lookerの個人フォルダ(Looker 6.20以前は「フォルダ」と呼ばれていたもの)に移動し、ダッシュボードを開いた時に実際に裏で起きていることは以下の様な流れになっています。

1.ユーザーがリンクをクリックし、個人用フォルダが表示される
2.ブラウザはそのフォルダに関する情報をLookerサーバに要求。「ここにLookやダッシュボード、また他のフォルダはありますか？」
3.Lookerサーバはその情報をブラウザーに返答。「はい。Look1、Look2を含むダッシュボードAがあります」
4.ブラウザにフォルダの内容が表示される
5.ユーザーがダッシュボードAのリンクをクリック
6.ブラウザは、LookerサーバにダッシュボードAに関する情報を要求
7.LookerサーバはLook1及びLook2の表示に必要なSQLクエリを生成し、データベースに送信
8.データベースはこれらのクエリの結果セットをLookerサーバに返答
9.Lookerサーバはクエリから取得したデータをブラウザに送信
10.ブラウザは、サーバから取得したデータを使ってダッシュボードをレンダリング

"遅延"の原因の切り分け

ここでは『データベース』『Lookerサーバ』『ブラウザ』の3つの主要なプレイヤーが登場し、これらの要素それぞれが、Lookerのパフォーマンスを構成しています。

以下、3つのコンポーネントがデータを取得し、表示するために必要としている作業について整理します。

データベースの負荷

特に複数データベースが同時実行されている場合、データベースがSQLクエリを実行するのには時間が掛かります。Explore、Look、ダッシュボードが結果を返すのに長い時間が掛かっている場合は、クエリの実行に時間が掛かっているのかもしれません。

[Admin]→[Query]パネル、またはデータベース関連のコンソールを確認する事で、データベースの負荷状況をより詳しく把握することが出来ます。

インスタンスの負荷

Lookerサーバ(Lookerインスタンス)では、サーバを利用するユーザーに可視化や情報を提供するために色々なことを行っています。インスタンス自体に大きな負荷が掛かっている場合は、クエリ実行を含まない、単純なタスク(フォルダのナビゲートなど)の読み込みに時間が掛かっている可能性があります。

ブラウザの負荷

上記の処理を経て、最後にブラウザ上でLookerから返されたデータが表示されます。

ブラウザで表示出来るデータの量は限られており、大量のデータを含むエクスプローラを開くだけでブラウザをクラッシュさせる可能性があります。

これはおおよそ、(セルあたりのデータ量) * (行数) * (列数)で測ることが出来ます。

大きなクエリが高速で稼働し、インスタンスに対してそのクエリ結果を高速に提供することは可能ではありますが、ブラウザではその結果を表示するのに時間が掛かるか、またはクラッシュする可能性があります。この場合、その大きなクエリを開いたユーザーだけが影響を受け、Lookerの他のページ、他のユーザは影響を受けません。

ネットワーク遅延

LookerはWebアプリケーションです。Lookerとのやり取りは全て、インターネットを介した情報の送信状況に依存します。

ネットワーク環境が不十分な場合、データベース、インスタンス、ブラウザのコンポーネント全てにそのパフォーマンスは影響します。ネットワーク遅延が発生している場合は、別のネットワークでLookerを使用している同僚に確認してみるか、Lookerサポートチームに問い合わせて事象の切り分けを行ってください。(問い合わせの際は、出来るだけ具体的に、アクセスしたのはどの時間帯で、どのページが遅くなったのかを共有してください)

まとめ

というわけで、Lookerにおける『パフォーマンス概要』のご紹介でした。

当エントリで紹介した『LookerはWebアプリケーションである』『ブラウザ上で処理する量には限界がある』というポイント、またLookerの特徴でもある『Lookerはデータの情報を(Lookerサイドに)持ってこない』というポイントなどを踏まえると、大方針としては『DB側で頑張る・何とかする』『Looker側で負荷の掛かるようなことはさせない』『そもそものデータ量、処理負荷を極力少なくさせる』というところを念頭に置くのが良さそうですね。